1. Technical Field of the Invention
This invention pertains to connection oriented client/server negotiation protocols. More specifically, it pertains to Telnet negotiation protocols for display and printer sessions allowing transfer of default or defined custom information within a confirmation record at the request of the client.
2. Background Art
There is a need in the art to enable a Telnet client when attempting to connect to a Telnet server to obtain connection status information including, for example, why did a connection request fail; why did a client auto-sign-on request fail; or what is the name of the virtual terminal display device assigned to this client. Auto-sign-on requests may fail, for example, because of an incorrect password or profile, a disabled or unknown profile, required encryption, expired user, and so forth.
This traditional Telnet support is accomplished in accordance with the following suite of Network Working Group Request for Comments (RFCs): Postel, J. and J. Reynolds, “Telnet Protocol Specification”, STD 8, RFC 854, May 1983; Postel, J. and J. Reynolds, “Telnet Option Specifications”, STD 8, RFC 855, May 1983; Postel, J. and J. Reynolds, “Telnet Binary Transmission”, STD 27, RFC 856, May 1983; VanBokkeln, J., “Telnet Terminal-Type Option”, RFC 1091, February 1989; Postel, J. and J. Reynolds, “Telnet End of Record Option”, RFC 885, December 1983; Alexander, S., “Telnet Environment Option”, RFC 1572, January 1994; Chmielewski, P., “5250 Telnet Interface”, RFC 1205, February 1991; Postel, J. and J. Reynolds, “Telnet Supress Go Ahead Option”, STD 29, RFC 858, May 1983; and Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 1700, October 1994.
The above suite of referenced RFCs jointly and severely fall short of providing an understanding of why a connection request has failed, and such is needed in the art to enable a client to correct the problem and retry a connection request such that it will be successful.
Similarly, when a connection request has succeeded, the client may need to know additional information, such as the name of the virtual terminal display device assigned to this client. Knowing the device name of a client connection is useful for audit logging, billing and error analysis for connected clients. Heretofore, screen scraping technology has been employed to acquire such a device name, relying on the screen layout to analyze the location of the device name on the screen. If the sign-on panel is altered such that the device name is in a different location, screen scraping fails. Also, this screen scraping technology does not work when the sign-on panel is bypassed.
In a client/server network, both client terminal and printer emulators often connect to a server on a host system. This host system can do different kinds of processing on the client session request based on client information, such as IP address, terminal or printer device requested, and auto-signon information. Some of the things that can be done include: accept or deny the connection based on the IP address or port; allow or disallow access to the request display or printer device for authority reasons, or switch the name of the requested device; route the client session to a particular sub-system on the host for processing, such as for workload balancing or language support; perform auto-signon services for the client, bypassing the logon screen; perform audit and security logging on the connection request; associate a client session with other client sessions running on the host, such as associating printer with a display session; and run a custom exit program to do “anything” the system owner desires.
It is often desirable to return the result of this processing to the client emulator. The client emulator can take advantage of information in various ways. Some of these include: post the name of the assigned terminal or printer device that was allocated by the host; post the name of an associated terminal or printer device that was linked to this session by the host; when printing, the client will know where (which printer, what building, what room) output can be picked up; tell the client what kind of security level the system is running, and which kind of password encryption is required; if a particular request, such as for device name, is rejected, retry with another device; if auto-signon is failing, client would like some indication why, such as password expired, profile disabled, no such profile, system lockout—so the problem can be automatically fixed; if system is overloaded, client would like to know session connection request was denied for workload reasons, such as off-peak hours, to try later or be redirected to another host; and read and interpret any custom information sent by the server side exit program.
These are only some of the possible things a client emulator could exploit, and there are many custom applications that could be done simply if both the server and the client could run exit programs on the session connection request. However, none of this can be done without a mechanism to return the results of this processing from the server to the client emulator. There is a need, therefore, in the art to allow client emulators to request that custom information be returned by the server thereby allowing the customers to exploit custom solutions between clients and servers.
It is, therefore, an object of the invention to provide an improved system and method for client/server session connection.
It is an object of the invention to provide an improved system and method for establishing a client/server connection.
It is a further object of the invention to provide an improved system and method for negotiating a client/server connection in a connection-oriented protocol.
It is a further object of the invention to provide a system and method allowing customers to exploit custom solutions between clients and servers.
It is a further object of the invention to provide a system and method for enabling client emulators to request that custom information be returned by servers.
It is a further object of the invention to provide a system and method for exploiting confirmation records technology to enable clients to receive custom information from servers during session connection.